Pl�doyer f�r einen neuen Grundkonsens im Publishing

Georg Obermayr Was ist die Zu­kunft des Publishing? Ein neues Jahr ist ein guter Zeitpunkt, solch grundlegende Fragen zu stellen. Je nachdem, wen man fragt, fällt die Antwort denkbar unterschiedlich aus: Die Zukunft ist die Cloud! Oder Apps! Oder Mobile! Oder Virtual Reality! Und so weiter … Jeder hat seine eigene Zukunft – die, die einem am besten in den Kram passt; die, die am besten zu dem passt, wofür man sich in der Vergangenheit interessiert hat. Ach, wenn es nur so einfach wäre!

Haben uns die letzten Jahre im Digitalisierungsrausch eines gezeigt, dann dies, dass es keine einfachen Antworten auf die Frage nach dem «nächsten grossen Ding» gibt. Dass wir es mit einer exponentiellen Entwicklungskurve zu tun haben. Dass wir mit unseren Erklärungen, die auf linearen Entwicklungsmodellen beruhen, nur selten weiterkommen. Was ist also die Zukunft des Publishing? Wir wissen es nicht. Das ist alles. Das ist die einfache Wahrheit.

Gerade weil diese Wahrheit so einfach – und bitter – ist, ist es wichtig, dass wir uns in der Branche auf einen neuen Grundkonsens einigen. Auf die Strategie hinter unseren Daten; darauf, wie wir mit unseren Inhalten und Gestaltungen umgehen möchten; darauf, wie und wo wir zukünftig miteinander unsere Produkte entwickeln möchten. Es geht um die Infrastruktur und das Klima, die Publishing in Zukunft erfolgreich halten. Es geht nicht um einen «Fünfjahresplan Publishing», nein, es geht um ein neues Zeitalter der Elastizität in einer Branche, die es gewohnt war, in Normierungen und eingespielten Abläufen zu denken.

Wie kann er aussehen, dieser neue Grundkonsens des Publishing? Folgende vier Thesen stellen wir auf der nächsten Doppelseite zu Diskussion:

1. Inhalte und Gestaltungen, die nicht strukturiert sind, sind zu träge für Veränderungen.
2. Wo Daten liegen, ist uninteressant, es kommt auf die Intelligenz der Infrastruktur an.
3. Statt riesiger All-in-one-CMS braucht es schlanke, vernetzte Systeme.
4. Wir müssen uns darauf einstellen, dass sich die Publishing-Reihenfolge laufend ändert.

Hier finden Sie eine nach Thesen geordneten Link-Liste.

These 1: Inhalte und Gestaltungen, die nicht strukturiert sind, sind zu träge für Veränderungen

Das ist eigentlich nichts Neues, (voll)automatische Produktion mit strukturierten Daten wird in vielen Betrieben seit Jahren praktiziert. Gerade wo viele Produktdaten in Katalogen wiedergegeben werden müssen, geht es schon lange nicht mehr anders. Trotzdem: Sobald der Sprung von standardisierten Darstellungen zu individuelleren Gestaltungen erfolgt, finden wir in der Praxis nur noch selten strukturierte Daten. Und hier liegt das Problem.

Um das zu verstehen, müssen wir uns vergegenwärtigen, dass wir nach wie vor Medienprodukte so erstellen wie zu Beginn des Desktop-Publishing: Wir haben ein Layoutprogramm, zie­hen Rahmen auf, platzieren Bilder und machen so lange Gestaltung, bis uns alles gefällt. Danach produzieren wir ein PDF, das genauso aussieht, wie wir es uns im Layout ausgedacht haben – WYSIWYG. Das funktioniert wunderbar, solange wir es nur mit dem einem statischen Medium zu tun haben, das Print nun mal ist. Aber dann haben wir in der Branche einen Fehler gemacht: Wir haben das WYSIWYG-Paradigma auf andere Medien übertragen, zuerst auf die aufkommenden Websites, dann auf Apps, auf E-Books usw. Moderne Web-CMS wie WordPress oder TYPO3 werden heute im Kern bedient wie die «alten» Print-Layoutprogramme. Wir legen Spalten an und gestalten rein.

Das funktioniert schon im Web nicht. Wer Responsive Design machen und seine Seiten sinnvoll «stapeln» will, der muss wissen, mit welchem Inhalt er es zu tun hat. Nur wenn klar ist, was der Inhalt bedeutet, der dargestellt wird, was seine Semantik ist, können sinnvolle Stapel- und Verschiebe-Entscheidungen getroffen werden. Das geht nur mit strukturierten Daten. Und dieses Problem potenziert sich mit der Zahl der Medien. Wer von der Smartwatch bis zum Smart-TV, vom Printprospekt bis zur Facebook-Anzeige konsistent kommunizieren will, muss sich mit anderen Formen der Datenhaltung beschäftigen.

Das Zauberwort für Medienproduktion mit strukturierten Daten lautet heute nicht mehr «Datenbank», sondern hört auf das seltsame Akronym API (Application Programming Interface). API, die Entwicklerschnittstelle – ein Begriff, den man sich merken sollte. Es geht auch in Zukunft darum, Modelle zu finden, in denen Inhalte abgelegt werden können, das Datenbank- oder Content-Modell. Durchdachte Content-Modelle sind dabei heute stets auf Wiederbenutzung ausgelegt: Sie beinhalten Varianten (Conversion-optimierte Headline für Online, Kurz-Headline, Print-Headline …), alternative Inhalte (vorgelesene Texte, Transskripte für Videos, alternative Texte für Bilder …) sowie sinnvolle Metadaten – und sie zerlegen den Inhalt in möglichst kleine atomische Blöcke. Das Entscheidende aber ist, dass diese Daten superflexibel von allen möglichen Stellen aus abgeholt werden können. Genau darum kümmert sich die API, das macht eine Schnittstelle. Eine solche API kann man selber bauen, etwa als PHP-Anwendung an die MySQL-Datenbank, bei speziellen Anbietern mieten, wie bei Contentful, einem Anbieter für Content-APIs, oder man kann bestehende CMS nutzen oder erweitern, beispielsweise mit WordPress oder Drupal.

Mit einem modernen Content-Modell und einer API lassen sich nicht nur Fliessband-Schraubenkataloge (das grosse Klischee der automatisierten Produktion!) bauen, sondern ausgefeilte Layout-Engines für Marketingunterlagen. Solche Technologien treiben heute bereits viele Websites an und werden für andere Medien zunehmend relevant. Mit der Möglichkeit, korrigierend grafisch eingreifen zu können, gelingt so der Sprung zu strukturierten Daten für alle Unternehmensbereiche. Aber Vorsicht! Das Ziel ist es nicht, alle Medien über einen Kamm zu scheren und die höchstmögliche Effizienz zu erreichen, nein: Ziel muss bleiben, jedes Medium ideal zu bedienen und in seinen Möglichkeiten auszureizen. Dass nicht der kleinste gemeinsame crossmediale Nenner entsteht, dafür sorgt das Quartett aus Content-Modell, API, Layout-Engine und grafischer Freiheit.

Mit all diesen tollen Dingen passiert plötzlich eines: Wenn einer der Tech-Riesen wieder das neuste Wunder-Gadget vorstellt, sitzen wir nicht mehr mit Schweissperlen davor und fragen uns, wie wir das technisch gestemmt bekommen. Wir wissen, dass wir die Daten aus unserer API verwenden können, komme was wolle.

These 2: Wo Daten liegen, ist uninteressant, es kommt auf die Intelligenz der Infrastruktur an

Wenn wir über APIs sprechen, kommen wir unweigerlich zu der Frage nach dem «Wo» unserer Daten: zentral in der klassischen IT, aber gilt das auch noch heute? Um die Veränderungen in der IT besser einordnen zu können, müssen wir zuerst einen Blick auf die heutigen Vertriebsmodelle von Software werfen.

Als Adobe die Creative Cloud herausbrachte und die klassische Kaufversion der Creative Suite einstellte, gab es einen riesigen Aufschrei in der Branche. Genutzt hat es nichts, Adobe war beharrlich und hat das Miet­-modell durchgezogen. Und, auch wenn es manchen aufstossen mag: Das wird sich nicht mehr ändern. Adobe wird heute in der Tech-Presse als Musterbeispiel für die Transformation des Einkommensmodells gefeiert und wäre blöd, hier noch Zugeständnisse zu machen. Software-Einkauf funktioniert heute so. Wer öfters Software evaluiert, findet zunehmend Mietmodelle, in manchen Produktsegmenten gibt es nichts anderes mehr.

Das Jammern über das Mietmodell resultiert auch hier aus einer Denke, die in der klassischen Printproduktion noch funktioniert haben mag, heute aber definitiv überholt ist: Heute kauft man keine Software mehr und setzt sie ein halbes Jahrzehnt ohne Änderungen ein. Die Medien und die Anforderungen ändern sich viel zu rasant. Es ist zwar ärgerlich, wenn Adobe die Edge-Suite einstellt, aber es ist folgerichtig: Solche Experimente werden wir in Zukunft viel häufiger sehen. Das Toolset aus InDesign/Photoshop/Illustrator mag für Print noch stabil sein, für andere Bereiche gibt es solche Standard-Toolsets nicht. Wer da nicht regelmässige Einnahmen aus Mietverträgen hat, wird als Softwareanbieter keine Experimente mit neuen Arbeitsmitteln finanzieren können – das werden auch die Hersteller merken, die noch auf klassische Lizenzmodelle setzen.

Das bringt uns zurück zur Frage nach der Speicherung der Daten. Die Creative Cloud ist nicht nur ein Lizenzmodell, sie hat auch eine echte Cloud-Komponente. Was als reiner Datenspeicher (ähnlich Dropbox oder Google Drive) begonnen hat, wird zunehmend intelligent: So ermöglichen Creative Cloud Libraries das Sharing von Design-Komponenten im Team und über Anwendungen hinweg. Ähnliche Wege werden bei der Integration des eigenen Stock-Foto-Services gegangen. Das alles sind Schritte, die in die richtige Richtung zeigen – gleichzeitig aber nur der Anfang sein können: Denn die reine Speicherung der Daten (egal ob in der Cloud oder lokal) ist wenig sexy, zentral ist die Intelligenz der Infrastruktur – was also mit diesen Daten passieren kann. Und gerade da kratzt Adobe die Möglichkeiten nur an.

Ein gutes Beispiel für diese Möglichkeiten ist Slack, der Instant-Messaging-Dienst für Unternehmen, der sich im letzten Jahr rasend verbreitet hat. Slack integriert APIs aus allen möglichen Quellen und lässt Drittsysteme Nachrichten in die Messaging-Kanäle ausgeben. Das Gleiche geht auch umgekehrt: Über Nachrichten können Nutzer mit den APIs kommunizieren und erhalten die Ergebnisse zurück in den Message-Stream. Es entsteht ein zentraler Kommunikationspunkt für all die dezentralen Services. Oder gar eine Art Betriebssystem für die Cloud? Auf jeden Fall eine neue Generation von Enterprise-Software. Noch ein Beispiel: Cloudinary ist ein Speicher-Service für Bilder in der Cloud. Vor allem aber ist Cloudinary auch eine API, eine, die Intelligenz in die Bildauslieferung bringt: Cloudinary erkennt Gesichter in Bildern, kümmert sich um den passenden Zuschnitt, konvertiert Formate oder erstellt Bildeffekte. Auch hier gilt: Wo die Daten liegen, ist die falsche Diskussion, es geht darum, so viel Intelligenz wie möglich zu realisieren.

These 3: Statt riesiger All-in-one-CMS braucht es schlanke, vernetzte Systeme

Intelligente Infrastrukturen – da klingelt es bei manchen Publishing-Veteranen: Da muss ein Redaktionssystem her – sind Redaktionssysteme doch das Paradebeispiel für vernetzte und «smarte» Printproduktion. Aber, sorry Leute, die Klassiker unter den Redaktionssystemen, allesamt sozialisiert und gedacht aus dem Print-Publishing heraus, sind oft zu statisch für die rasante digitale Produktion. Viele Firmen können die monolithischen Monster, die sie sich ins Haus geholt haben, nur noch schwer beherrschen. Und: Ja, einige Systeme können heute schon mal einen Tweet absetzen, aber das alleine reicht nicht.

Abseits der klassischen Redaktionssysteme hat sich eine spannende Spielwiese an frisch gedachten Lösungen entwickelt: TruEdit etwa ist ein Print-Redaktionssystem, in dem die Redaktoren mit Word und Excel in Richtung InDesign arbeiten. So werden die Vorteile von zwei Systemen miteinander kombiniert. Auch Ansätze, in denen mit Google Docs als Redaktionstool gearbeitet wird, sind spannend und zeigen:lLieber mehrere schlanke Systeme, die eine Aufgabe sauber erledigen, miteinander kombiniere, als versuchen, alles in einem System abzubilden.

Dies ist vor allem vor dem Hintergrund smart, dass laufend dezentrale Medienkanäle entstehen: Facebook Instant Articles, Apple News oder Snapchat Stories sind gute Beispiele für diese Kanäle, die sich hinter verschlossenen Wänden («walled gardens») abspielen und auf eigene proprietäre Dateiformate setzen. Gewinnen diese Kanäle an Bedeutung, geht die Relevanz der eigenen Homepage gleichzeitig zurück. Das ist eine Entwicklung, die andere Branchen ähnlich erleben (vgl. Buchungsportale und die Hotellerie) und die man durchaus kritisch sehen kann – uns als Publishing-Strategen hilft es aber nichts. Wir müssen auf diesen Plattformen vertreten sein, um die Reichweiten zu halten, und: Mit weiteren «Nischenmedien» ist zu rechnen.

Viele dieser Plattformen werden so schnell verschwinden, wie sie gekommen sind. Gerade deshalb ist es wenig sinnvoll, den grossen Print-Monolithen immer neue Content-Transformationen aus fertigen Layouts abzuverlangen. Dann lieber mit möglichst schlanken Systemen arbeiten, die für genau eine Aufgabe zuständig sind, über APIs kommunizieren und ihre medienneutralen Inhaltspakete austauschen. Auch so entsteht die vielfach beschworene höhere Reaktionsfähigkeit.

Noch ein Beispiel für ein gelungenes Publishing-System-Experiment: Die( New York Timess hat für einen Live-Ticker das Publishing über die erwähnte Chat-Lösung Slack realisiert. Dazu wurde Slack zu einer Art Mini-Publishing-System aufgebohrt, inklusive Revisions- und Genehmigungsprozessen. Soviel zur Power von APIs und schlanken Systemen. Und: Das hört sich nicht nur cool an – es zeigt, dass Publishing heute mehr Spass machen kann – ja muss! –, als wir es aus den oft verbohrten Print-Umgebungen kennen. Nicht umsonst liefern sich einige amerikanische Publishing-Häuser gerade einen Wettbewerb um die innovativsten, am frischesten gedachten Publishing-Lösungen. Die Antwort auf die zunehmende Medienproliferation ist dabei nicht «mehr Komplexität», sondern «mehr Einfachheit». Auch hier kratzen wir gerade erst an der Spitze des Eisberges. Und das bringt uns nahtlos zur letzten These:

These 4: Wir müssen uns darauf einstellen, dass sich die Publishing-Reihenfolge laufend ändert

Publishing-Reihenfolge bedeutet, welches Medium zuerst kommt. Zu besonderer, trauriger Berühmtheit haben es die Begriffe «Print first» und «Digital first» gebracht. Warum traurig? Ersterer zeigt das überkommene Festhalten an Print als «erstem» Medium, während für einen Grossteil der Leute digital längst die erste Anlaufstelle ist. «Digital first» steht dagegen für einen aktionistischen Pendelausschlag ins Digitale, der gerne übersieht, dass auch Print in Zukunft eine Relevanz haben wird. Was also ist die richtige Publishing-Reihenfolge?

Zuerst müssen wir uns anschauen, welche Auswirkungen es hat, wenn sich die Publishing-Reihenfolge ändert. Dazu gibt es aktuell einen interessanten Trend, der sich an einem Tool von Callas Software zeigt: pdfChip erstellt aus HTML-Websites Print-PDF. Richtig gute Print-PDF, denn Callas hat für alle Print-Finessen wie Sonderfarben, Farbmanagement oder Überdrucken eigene CSS- und HTML-Erweiterungen implementiert. Warum ist das spannend? Weil für viele Unternehmen mittlerweile die Website das «erste» Medium ist. Copy&Paste aus dem Print-Stehsatz ins Web-CMS (Print first) ist schon lange nicht mehr angesagt. Was liegt daher näher, als auf Basis der HTML-Seiten das Printmedium abzuleiten? So ist Printproduktion aus HTML-Dateien eine Entwicklung, die es definitiv zu verfolgen gilt – und die sich noch deutlich verstärken dürfte. Vor diesem Hintergrund ist nicht mal die klassische Print-Toolkette rund um das Layoutprogramm noch sicher.

Was ist die Konsequenz daraus? Nicht, dass «HTML first» jetzt die Zukunft ist! Schauen wir erneut auf die zunehmende Dezentralisierung der Kanäle, sehen wir, dass eine einfache Antwort nicht mehr gegeben werden kann. Was würden wir mit «Facebook Instant Articles first» tun? Oder mit «Instagram first»? Oder mit «WeChat first»? Alle diese Kanäle finden heute in der Kommunikation und der Nutzerwahrnehmung gleichzeitig und überlappend statt. Mit dieser Flexibilität kann eine technische Lösung, die von einem bestimmten Startmedium ausgeht, nur noch schwer mithalten.

Die Antwort auf «first» muss anders ausfallen: technisch und strategisch. Technisch geht es nur «Content first». Es braucht diese Modelle, die unsere Inhalte in Strukturen bringen und sie möglichst medienneutral abbilden. Dann können wir auf ein neues «First» schnell und ökonomisch reagieren – ausser, das neue Medium ist so disruptiv, dass wir zuerst neue Formen der Aufbereitung finden müssen. Deshalb lautet die zweite, strategische Antwort «Story first». Na­türlich. Bevor wir wissen, in welche Modelle wir unsere Kommunikation packen können, müssen wir überhaupt mal wissen, was wir kommunizieren wollen, was unsere Story ist. Ohne geht es nicht – die Kommunikation wäre inhaltsleer. Daraus leitet sich alles andere ab. Und mit «alles» ist wirklich alles gemeint: Der Inhalt der Kommunikation sollte die technische Infrastruktur, den Datenaufbau und natürlich das Content-Modell massgeblich mitbestimmen.

Was ist denn nun das Publishing der Zukunft?

So könnte es wirklich aussehen, das Publishing der Zukunft: ein Publishing, das elastischer, das dynamischer ist als das, das wir heute kennen. Eines, das den Ballast aus der Printproduktion hinter sich gelassen hat, ohne die Tradition aus Print zu vergessen.

Publishing in der Zukunft wird mehr eine offene Schnittstelle, eine API, sein als ein grosser technologischer Block. Publishing, das ist eine API zur Kommunikation mit Menschen.

Hier finden Sie eine nach Thesen geordneten Link-Liste.